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Abstract. Wc describe L-FLAT, a Logtalk Toolkit for teaching For- 
mal Languages and Automata Theory. L-FLAT supports the definition 
of alphabets, the definition of orders over alphabet symbols, the partial 
definition of languages using unit tests, and the definition of meciia- 
nisms, which implement language generators or language recognizers. 
Supported mechanisms include predicates, regular expressions, finite au- 
tomata, context-free grammars, Turing machines, and push-down au- 
tomata. L-FLAT entities arc implemented using the object-oriented fea- 
tures of Logtalk, providing a highly portable and easily extendable frame- 
work. The use of L-FLAT in educational environments is enhanced by 
supporting Mooshak, a web application that features automatic grading 
of submitted programs. 

Keywords: logic programming, formal languages, automata theory, 
educational tool. 



1 Introduction 

L-FLAT [1] is a free, open source, Logtalk [2,3] Toolkit for teaching Formal 
Languages and Automata Theory. It supports the definition of alphabets and 
total orders over alphabet symbols, the partial definition of languages using unit 
tests, and the definition of mechanisms, which attempt to implement a particular 
language, using either a language generator or a language recognizer. Supported 
mechanisms include predicates, regular expressions, finite automata, context-free 
grammars, push-down automata, and Turing machines. 

As an educational tool, L-FLAT implements algorithms and concepts taught 
in typical courses of Formal Languages and Automata Theory (FLAT). These 
include algorithms for recognizing and generating words, for converting between 
different types of mechanisms, for querying different aspects of the mechanisms, 
for checking if a mechanism is deterministic, for making finite automata deter- 
ministic, and for minimizing mechanism definitions. L-FLAT is designed primar- 
ily as an interactive tool with a command-line interface but its use in educational 



environments is enhanced by supporting Mooshak, a web application that fea- 
tures automatic grading of submitted programs. To maximize its usefulness, 
L-FLAT is implemented as a highly portable, easily extensible tool. 

The remainder of the paper is organized as follows. Section 2 briefly char- 
acterizes Logtalk as a programming language. Section 3 presents an extended 
tutorial example, illustrating some of the main L-FLAT features. Section 4 gives 
an overview of the current L-FLAT implementation. Section 5 describes typi- 
cal classroom usage scenarios for L-FLAT. Section 6 discusses the L-FLAT — 
Mooshak integration. Section 7 compares L-FLAT with related work. Section 8 
describes the current implementation status and outlines future work. 

2 Lotalk in a Nutshell 

L-FLAT is implemented in Logtalk, an object-oriented logic programming lan- 
guage that can use most Prolog implementations as a back-end compiler. Logtalk 
focus in code encapsulation and code reuse features, providing an alternative to 
Prolog module systems. Logtalk supports classes, prototypes, parametric objects, 
categories (fine-grained units of code reuse), and separation between interface 
and implementation using protocols. We take advantage of all these features in 
L-FLAT. Logtalk uses object as a generic term: an object can play the role of e.g. 
an instance, a class, or a prototype. The relations between objects, protocols, 
and categories defining different patterns of code reuse. Logtalk entities can be 
static, defined in source files, or dynamic, created at runtime. Computations are 
performed by sending messages (corresponding to predicates) to objects. Logtalk 
enforces predicate encapsulation (predicates can be declared public, protected, or 
private) and features a clear distinction between predicate declaration and pred- 
icate definition (using a closed-world assumption when a predicate is declared 
but not defined). 

3 A Tutorial Example 

In this tutorial, we will use the language comprised of all sequences of as and 
bs with an even number of bs as a running example. We start with a partial 
language definition, followed by six different mechanisms, acting as recognizers 
or generators for the language. We end this section with examples of defining 
alphabets and alphabet orders. All source code is included in the current L-FLAT 
distribution. 

3.1 Language Definitions 

Languages are partially defined by stating three elements: their alphabet, a set of 
positive unit tests, and a set of negative unit tests. Listing 1.1 provides an object 
definition for our example language. Each unit test defines a word, a sequence 
of alphabet symbols (represented as a list), that should be either recognized or 
rejected by a language mechanism. 



Listing 1.1. Sequences of as and bs with an even number of bs 



:- obj ect (evenL , 

instantiates (language ) ) . 

alphabet ( [a , b] ) . 

positive ( [] ) . 
positive ([a, a, a]) . 
positive ( [b , b] ) . 
positive ( [a,b,b] ) . 
positive ([b,b, a, a]). 

negative ( [b] ) . 
negative ( [b,b,b] ) . 
negative([b,a,a]) . 
negative ( [a,a,b] ) . 
negative ([b,a,a,b,b,a,a]) . 

: - end.ob j ect . 



Teachers often help the students define an initial set of unit tests while keeping 
a more comprehensive set of unit tests private for grading. A test_mechanism/l 

predicate, defined in the language class, can be used by students to test their 
mechanism definitions against a language unit tests (see Listing 1.2 for an usage 
example of this predicate). 

3.2 Mechanism definitions 

A mechanism attempts to implement a specific language, acting as a language 
generator, as a language recognizer, or both. As the names suggest, a language 
generator can generate words belonging to a specific language while a language 
recognizer can recognize if a word belongs to a specific language. 

Predicate Mechanisms The most basic mechanism that we can define is a 
predicate. Listing 1.2 provides an example. Predicate mechanisms should pro- 
vide a suitable definition for the object predicate accept/1, used for recognizing 
language words. The evenP object defines this predicate by using the services 
of the object word, which provides a set of utility predicates for constructing, 
decomposing, and sorting words. 

Listing 1.2. Predicate mechanism for the evenL language 

:- obj ect (evenP , 

instantiates (predicate)) . 

:- initialization ( 



evenL : : test_mechanism(evenP) 

) . 

alphabet ( [a , b] ) . 

accept (Word) : - 

alphabet (Alphabet) , 

word :: word_alphabet (Word , Alphabet) -> 
word :: occurs (b , Word, N) , =:= N mod 2. 

: - end_ob j ect . 



The evenP object also defines an initialization goal for testing the mechanism at 
loading time using the unit tests of the evenL language defined in Listing 1.1. 

Regular Expression Mechanisms Listing 1.3 shows a regular expression for 
the evenL language. Regular expressions arc defined using the object predicate 
expression/1. L-FLAT uses the infix operators + and * for expressing alterna- 
tion and concatenation, and uses the postfix operators "* and "+ for expressing 
repetition of a sub-expression. 

Listing 1.3. Regular expression for the evenL language 

:- object (evenRE , 

instantiates (re ) ) . 

:- initialization ( ( 

evenL : : test_mechanism (evenRE) , 
: : fa(FA) , 

FA : : determine (FAD) , 
FAD : : minimise (FAM) , 
FAM : : rename (FAR) , 
FAR : : show 

)) . 

expr es sion ( ( a + b * a"* * b)~*). 
: - end_ob j ect . 



The initialization goal of the evenRE object illustrates how to convert a regular 
expression into a deterministic finite automaton. For educational purposes, each 
step of the conversion is implemented by a different predicate. Upon loading of 
the evenRE object, the output in Listing 1.4 is generated. 

Listing 1.4. Output generated when loading the evenRE regular expression 

Starting tests of evenRE against evenL . . . 
. . . tests finished 



FINITE AUTOMATON : 

fa(sl, [sl/a/sl , sl/b/s2 , s2/a/s2 , s2/b/sl] , [si]) 
Initial state : si 
Transitions : 

si - a -> si 

si - b -> s2 

s2 - a -> s2 

s2 - b -> si 
Final states: [si] 
Deterministic: yes 



The generated automaton, represented using a fa/3 compound term, is a Logtalk 
parametric object proxy [4], i.e. an instantiation of the identifier of the para- 
metric object faClnitial, Transitions, Finals), defined by L-FLAT (see next 
section). Parametric object proxies provide a compact representation for sim- 
ple objects and are often used to represent the result of mechanism conversion 
predicates. 

L-FLAT mechanisms understand a word/1 message for generating language 
words, as illustrated in the example query in Listing 1.5. 

Listing 1.5. Generating evenL words using the evenRE regular expression 
I ?- evenRE :: word (Word) . 



Word = [] ; 

Word = [a] ; 

Word = [a, a] ; 

Word = [b, b] ; 

Word = [a, a, a] ; 

Word = [b , b , a] ; 



Finite Automaton Mechanisms Listing 1.6 shows a finite automaton defi- 
nition for the evenL language. The transitions between states are expressed as 
FromState/Symbol/ToState compound terms. 

Listing 1.6. Finite automaton for the evenL language 

:- ob j ect ( evenFA , 

instantiates (f a) ) . 



init ial ( 1 ) . 

transitions ( [1/a/l , l/b/2 , 1ls.l1, 2/b/l]). 
finals ( [1] ) . 



- end_ob j ect . 



Any L-FLAT mechanism may alternatively be represented as a compound term, 
that can be interpreted as a parametric object proxy, as illustrated in the pre- 
vious section. In fact, all L-FLAT mechanisms, represented by classes, have a 
corresponding parametric object instance. Listing 1.7 shows the definition of the 
fa/ 3 parametric object. 

Listing 1.7. Parametric object fa/3 



:- ob j ect ( f a ( _Init ial , _Transitions , _Finals), 
instantiates (f a) ) . 

init ial ( Initial ) :- 

parameter (1, Initial), 
transitions (Transitions ) :- 

parameter (2, Transitions). 

f inals ( Finals ) :- 

parameter (3, Finals). 

: - end_ob j ect . 



Parametric objects and object proxies provide an alternative representation for 
simple mechanisms and greatly simplify both L-FLAT internal tasks (e.g. con- 
version between mechanisms, bypassing the need of dynamically creating new 
objects at runtime) and student interaction with L-FLAT (e.g. entering a mech- 
anism definition at the interpreter prompt). 

Context-free Grammar Mechanisms Listing 1.8 shows an example of a 
context-free grammar for the evenL language. Grammar rules are represented as 
Head->Body where Head is a non-terminal symbol and Body is a (possibly empty) 
list of symbols. 

Listing 1.8. Context-free grammar for the evenL language 



:- ob j ect ( evenCFG , 

instantiates (cf g) ) . 

start_symbol ( ' S ' ) . 

rules ( [ 

( ' S ' -> [a , ' S ' ] ) , 

( ' S ' -> [b , ' S ' , b] ) , 

( 'S' -> ['S' , 'S']) , 

CS' -> []) 

]) . 



- end_ob j ect . 



Pushdown Automaton Mecheinisms Listing 1.9 shows an example of a 
pushdown automaton for the evenL language. The state transitions are rep- 
resented as SourceState/PoppedSjrmbol/InputSjnnbol/TargetState/PushedSymbols 
compound terms. 



Listing 1.9. Pushdown automaton for the evenL language 



:- ob j ect ( evenPDA , 

instantiates (pda) ) . 

initial (p) . 

initial_stack_symbol (z) . 
transitions ( [ 

p/z/a/p/ [z] , 

p/z/b/q/[z] , 

q/z/a/q/ [z] , 

q/z/b/p/[z] 

]) . 

finals ( [p] ) . 



: - end_ob j ect . 



Turing Machine Mechanisms In Listing 1.10 wc show an example of a 
Turing machine for the evenL language. Each state transition is represented 
as a SourceState/ReadSymbol/ WrittenSymbol/MoveSymbol/TargetState compound 
term. 

Listing 1.10. Turing machine for the evenL language 

:- ob j ect ( evenTM , 

instantiates (tm) ) . 

init ial ( qO ) . 
transitions ( [ 

qO/'B'/'B'/'R'/ql, 

ql/a/a/'R'/ql, 

ql/b/b/ ' R ' /q2 , 

ql/'B'/'B'/'R'/q3, 

q2/a/a/'R'/q2, 

q2/b/b/ 'R'/ql , 

q2/'B'/'B'/'R'/q4 

]) . 

finals ( [q3] ) . 
: - end_ob j ect . 



L-FLAT provides a diagnostics predicate, diagnostics/0, that can be used by 
the student to check mechanisms definitions for possible problems. Listing 1.11 
shows the output of this predicate for the evenTM Turing machine. 

Listing 1.11. Running diagnostics/O on the evenTM Turing machine 

I ?- evenTM :: diagnostics . 

Starting diagnostics of evenTM . . 
Warning in evenTM : 

undefined transition for state/ 
Warning in evenTM : 

undefined transition for state/ 
Warning in evenTM : 

undefined transition for state/ 
Warning in evenTM : 

undefined transition for state/ 
Warning in evenTM : 

undefined transition for state/ 
Warning in evenTM : 

undefined transition for state/ 
. . . diagnostics finished 
yes 



L-FLAT allows the user (usually the teacher) to define the level of detail of 
error messages. Warnings during the compilation of cintitics (c.g languages and 
mechanisms) can be turned off, set to provide minimal information (e.g. when 
using Mooshak for student grading), or set to provide detailed information. Error 
messages (e.g. when testing a mechanism using the corresponding language unit 
tests) can also be configured to either reveal or conceal the cause of the problem. 

L-FLAT mechanisms also accept a tracing/ 1 message that allows students 
to trace the parsing of a language word. An example using the evenTM Turing 
machine is presented in Listing 1.12. 

Listing 1.12. Tracing parsing a evenL word using the evenTM Turing machine 

I ?- evenTM :: tracing ( [a ,b ,b , a] ) . 

TRACING TURING MACHINE: 
Name : evenTM 

Traced word: [a, b, b, a] 

At least one execution path stops at an 

acceptance state . 

Word accepted. 

Traced steps : 

>B a b b a B qO 

B>a b b a B ql 

B a>b b a B ql 

B a b>b a B q2 



symbol qO/a 

symbol qO/b 

symbol q3/a 

symbol q3/b 

symbol q4/a 

symbol q4/b 



Bab b>a B ql 

B a b b a>B ql 

B a b b a B>B q3 

yes 



3.3 Alphabets and Orders 

L-FLAT supports the definition of alphabets by specifying an expression that 
returns the list of alphabet symbols, as exemplified in Listing 1.13. 

Listing 1.13. A simple alphabet, bits, for a binary language 

: - obj ect (bits , 

instantiates (alphabet)) . 

expression ([0,1]). 

: - end_ob j ect . 



It is also possible to compose alphabets. For example, Listing 1.14 illustrates 
how to define a new alphabet, decimal, by reusing the bits alphabet. 

Listing 1.14. Defining a new alphabet, decimal, by reusing another alphabet 

:- obj ect (decimal , 

instantiates ( alphabet ) ) . 

:- initialization ( ( 
: : show , 
: : diagnostics 

)) . 

expression (bits + [2,3,4,5,6,7,8,9]). 
: - end_ob j ect . 



Listing 1.15 defines an order over the bits alphabet symbols. Alphabet orders 
can be used to perform lexicographic sorting of language words. We can define 
as many orders as needed over the same alphabet. The default order is expressed 
by the ordering in the list of symbols returned by alphabet expressions. 

Listing 1.15. Defining an order over the symbols of alphabet bits 

:- object(up, 

instantiates (order) ) . 



alphabet (bits ) 



sequence ([0,1]) 
- end_ob j ect . 



3.4 Playing With Words 

L-FLAT includes an utility object, word, providing a set of predicates for e.g. 

computing words from regular expressions, generating words from an alphabet, 
generating words giving a specific word an order, and decomposing words into 
prefixes, sufiixes, and sub-words. Listing 1.16 shows an usage example, using the 
alphabets and orders defined above (in the first query, w~n means w repeated n 
times, when n >= 0; w~(-l) moans the reverse of w). 

Listing 1.16. Using the word utility predicates 

I ?- word : : compute.word ( [0 , 1] "2* [1 , 1 , 0] * ( -1) , Word). 

[0,1,0,1,0,1,1] 

yes 

I ?- word :: word.alphabet (Word , bits). 
[] ; 

[0] ; 

[1] ; 
[0,0] ; 



I ?- word::lexically_ordered(Word, [1,1,1], up). 

[] 

[1] 

[1,1] 

[1,1,01 _G1399] 
[1,0 1 _G1396] 
[01 _G1393] 
yes 

I ?- word :: mixed_ordered (Word , [1,1,1], up). 
[] 

[_G1407] 

[_G1407 , _G1410] 

[1,1,0] 

[1,0, _G1413] 

[0, _G1410 , _G1413] 

yes 

I ?- word : : next_word ([1,1,1] , Word , up ) . 

[0,0,0,0] 

yes 



I ?- word :: subword (Word , [1,2,3,4,5]). 
[] ; 
[1] ; 
[] ; 
[1,2] ; 



4 Implementation 

Alphabets, orders, languages, and mechanisms are implemented by taking ad- 
vantage of the object-oriented features of Logtalk. All these kinds of entities 
are implemented as sub-classes of a generic L-FLAT entity root abstract class, 
thus sharing a common protocol for printing, validating, and diagnosing pos- 
sible problems. Mechanisms are implemented using a class hierarchy, allowing 
easy sharing of common code using inheritance. Concrete alphabets, orders, lan- 
guages, and mechanisms can be defined either as instances of these classes or as 
Prolog facts interpreted as parametric object proxies by Logtalk, depending on 
their complexity. The current implementation has 4000 lines of Logtalk source 
code (including basic object and predicate documentation-^), defining 19 classes, 
some prototypes {stand-alone objects, such as word, encapsulating utility predi- 
cates), some protocols (interfaces), 16 parametric objects (necessary to support 
object proxies), and 3 objects dedicated to user interaction and Mooshak sup- 
port. Figure 1 in the Appendix depicts the main L-FLAT entities and the main 
predicates implemented by these entities'* 

The recognition and generation operations - (accept/1, accept/2 and word/l) 
- are semi-algorithms, i.e. proccdmes not ensuring termination. They are imple- 
mented in a generic way inside; the mechanism abstract class, which is a super-class 
of all the L-FLAT mechanisms. These generic definitions are inherited and used 
without modification by the finite automata, the push-down automata, and the 
Turing machines. However, regular expressions and context-free grammars pro- 
vide specialized definitions that ensure termination. In the case of context-free 
grammars, we use the relatively advanced but well known technique of converting 
each context-free grammar into its qiiasi-lambda-frec; and chain-free form. 

A challenging task was coping with the non-termination of the semi-algorithms. 
Our solution was to use the breadth-first search strategy with loop detection: 
we build in parallel all the execution paths that may lead to success (called vi- 
able execution paths) and prune any loop once detected. This completely solves 
the problem for finite automata. However, non-termination remains an issue for 
those push-down automata and Turing machines with the property that none 

^ This documentation can be automatically converted in HTML or PDF, providing a 

reference manual for using and extending L-FLAT. 
* A full entity diagram is included in the current L-FLAT distribution and can also 

be found here: http: //code .google . com/p/lflat/source/browse/triink/lflat. 

ent ity_diagram . pdf 



of the execution paths wih ever reach success but there is at least one execu- 
tion path endlessly generating distinct machine configurations, never repeating 
a machine configuration. In this situation the program runs out of memory or 
reaches a timeout, causing an exception to be raised and caught; the word being 
tested is neither accepted nor rejected. 

Most of the L-FLAT code is based on the formal concepts and algorithms 
taught in classes, translated as straightforwardly as possible into Logtalk. There- 
fore, in general, the students should be able to examine the L-FLAT source code 
and recognize the concepts and algorithms they have learned in classes. 

L-FLAT is available under the GNU General Public License v2 and can be 
downloaded from the Google Code web site. The current distribution includes a 
set of examples based on teaching textbooks [5]. 

5 L-FLAT in the Classroom 

Although L-FLAT is a recent development, our past experience with its pre- 
cursor, P-FLAT [6, 7], provides us with valuable insight on typical and success- 
ful classroom usage scenarios. L-FLAT is designed as an interactive tool that 
helps students perform experiments when learning formal languages and au- 
tomata theory. The partial definition of a language from an alphabet and a set 
of positive and negative unit tests allows the student to interactively test his/her 
language recognizers (generators), tracking language words that are not prop- 
erly recognized (generated) or wrongly recognized (generated). The mechanism 
testing informative warnings and error messages and the mechanism tracing fea- 
tures helps the student to diagnose and correct wrong definitions. L-FLAT can 
also play an important role in student self- assessment. Given a formal language 
specification or an informal description, the student can define unit tests that 
represent his/her understanding of which words belong and which words don't 
belong to the language, and implement one or more supported mechanisms, 
testing them against the partial language definition. The use of L-FLAT in the 
classroom, both in student self-assessment and teacher grading tasks, is further 
enhanced by its integration with Mooshak, described next. 

6 MooshcLk Integration 

Mooshak [8] is a web-based tool for managing programming contests, with au- 
tomatic judging, often used in undergraduate programming contests. It is also 
increasingly being used as a teaching tool with several goals: to drive program- 
ming related exercises, to pre-evaluate assignments, and more simply to receive 
and validate assignment submissions without any pre-evaluation. In practice, 
the students tend to interact with Mooshak from home, although using it in the 
classroom is also possible. 

Mooshak works by accepting, compiling, and running program submissions, 
comparing the resulting output against the expected output, and giving imme- 
diate feedback. Multiple case tests are used to evaluate the correction of each 



solution. The time and space complexity of the solution can also be assessed by 
defining computation time and memory usage limits when setting up a contest. 

L-FLAT is distributed with a compatibility layer for allowing its use by 
Mooshak. A demo Mooshak contest, named L-FLAT Demo and consisting of ten 
problems, is available from the L-FLAT web site [1]. 

The Mooshak interface is attractive for students due to its simplicity. There 
is no need to install and setup Logtalk and L-FLAT or to study L-FLAT and its 
commands. The student simply reads the statement of each problem, writes a 
solution following the syntax of a model example, submits the solution, and gets 
instant feedback. This user experience is necessarily limited when compared with 
using L-FLAT directly. However, when the use of L-FLAT is not mandatory in 
a course, the Mooshak interface is probably the best way to drive most students 
to take advantage of L-FLAT, even if in a simplified way. 

Another point is that using L-FLAT through Mooshak is somewhat com- 
pelling, and has some potential to increase the average student's interest for the 
course, assuming that it is available for a long running contest that includes 
most of the exercises of the course. The general experience with such a contest 
feels like an interactive game of solving puzzles, and there is a motivation for 
trying to reach higher and higher scores. 

We end this section with an example illustrating how L-FLAT works with 
Mooshak. Consider the following problem statement: 

Please create a context-free grammar, "evenCFG", that generates the 
language of the sequences of "a"s and "b"s, where the symbol "b" ap- 
pears an even number of times. Do not forget that zero is an even number. 

There are infinitely many solutions for this problem. Suppose that the student 
submits the solution found in Listing 1.8, which is correct. Responding to this 
submission, Mooshak runs a command that starts Logtalk and loads the L-FLAT 
application and the submitted object. 

In our demo contest there is one single input test file per problem as an L- 
FLAT language instance can include multiple unit tests. The content of the input 
test file is the evenL object found on Listing 1.1, with the following initialization 
directive added: 

Listing 1.17. evenL language initialization for testing the evenCFG mechanism 

:- init ializat ion ( ( 

contests : : diagnostics (evenL) , 

contests : : check_definition(cfg, evenCFG) , 

contests : : diagnostics (evenCFG) , 

contests :: test.mechanism ( evenL , evenCFG), 

contests : : f inish_cliecking 

)) . 



This initialization directive allows the test to auto-nm upon loading of the evenL 
object. The initialization goal performs a basic validation of the evenCFG context- 
free grammar and checks it against the positive and negative examples defined 



on the evenL language. As the particular submission we are considering is correct, 
the generated output matches exactly the contents of the output test file: 

Listing 1.18. Output test file contents for checking the evenCFG mechanism 



Starting diagnostics of evenL . . . 

. . . diagnostics finished 

evenCFG is well defined 

Starting diagnostics of evenCFG . . . 

. . . diagnostics finished 

Starting tests of evenCFG against evenL 
. . . tests finished 
Finished checking 



Thus, Mooshak accepts the submission. Any ill-formed submission or any well- 
formed submission incompatible with the unit tests would be rejected by Mooshak 
as a consequence of the extra messages generated. 

7 Related Work 

L-FLAT development was bootstrapped by a full Logtalk rewrite of P-FLAT, 
a Prolog Toolkit for teaching Formal Languages and Automata Theory. This 
rewrite, motivated by increasing maintenance problems of P-FLAT due to its 
growing code base, has important advantages over the original application while 
retaining and expanding its features. First, much improved compatibility with 
Prolog compilers, inherited from the Logtalk portability itself.^ The original P- 
FLAT implementation used Prolog features only available in some compilers, 
severely restricting its portability. Second, the refactoring of the original source 
code lead to a significant reduction of the number of arguments of most predi- 
cates, resulted in smaller and simpler predicate definitions. Despite the fact that 
P-FLAT worked with general concepts (e.g. Mechanism) and specializations of 
those concepts (e.g. Turing machine), it was implemented as a plain Prolog ap- 
plication. The low level solution used for simulating inheritance and code sharing 
within the application required the presence of extra arguments in most predi- 
cates and a complex machinery just to keep track of entity identifiers (around 
8% of the original code). Third, the consequent code modularization further 
makes the code easier to understand, improves reliability, and simplifies future 
extension of the application, by its current developers or by external contrib- 
utors. For example, we recently added support for context-free grammars and 
Turing machines, which were easily implemented as sub-classes of the existing 
mechanism abstract class, thus inheriting useful features already in-place common 
to all mechanisms. In the old P-FLAT application, adding a mechanism required 
widespread and thus more error-prone changes to the code base. 



^ Using Logtalk 2.40.1, L-FLAT runs as-is on B-Prolog, Ciao Prolog, CxProlog, 
ECLiPSe, GNU Prolog, Qu-Prolog, SICStus Prolog, SWI-Prolog, XSB, and YAP. 



When compared with related educational tools, L-FLAT innovates by allow- 
ing languages to be partially defined using unit tests, which can then be used 
to test the formal language mechanisms. This feature increases the ability of 
the students to use L-FLAT as an exploratory tool. Moreover, the combination 
of language unit tests with the textual and declarative definition of mechanisms 
provides the necessary support for using L-FLAT with Mooshak, further enhanc- 
ing its pedagogical value. 

The FSA Utilities toolbox [9] is an open-source Prolog implementation of a 
set of utilities for working with regular expressions, finite-state automata, and 
finite-state transducers. This toolbox implements several algorithms for con- 
structing finite automata from regular expressions and for manipulating finite 
automata. Although not as portable as L-FLAT, the FSA toolbox includes a 
SICStus Prolog specific graphical user interface, besides a command-line inter- 
preter. It is also possible to compile finite automata as stand-alone cxecutables 
(using the C programming language). The FSA toolbox can also be used as an 
education tool (extensive course material is available from the software web page 
[10]), as a command-line filter utility, or as a general purpose Prolog library. 

Similar educational tools exist written in other programming languages. The 
best know example is JFLAP [11], an application written in Java. JFLAP pro- 
vides a set of graphical tools for visually designing and simulating different 
mechanisms. However, it does not support user-written textual definitions of 
mechanisms as found in L-FLAT. Although the current version of L-FLAT only 
provides a textual interface, it provides some significant advantages: declarative 
definition of alphabets, orders, languages, and mechanisms; user-defined opera- 
tors, which improve readability; built-in unification and non-determinism, mak- 
ing it simple to define and explore non-deterministic mechanisms; inherent in- 
teractive nature of the Logtalk/Prolog interpreter, which favors experimentation 
by students learning FLAT concepts. The textual interface, by itself, simplifies 
running L-FLAT with Mooshak. 

8 Conclusions and Future Work 

We are currently inspecting, revising, and documenting L-FLAT. Our goal is 
to ensure a stable foundation for future development and to provide teachers 
and students with a reliable and friendly tool for teaching and learning Formal 
Languages and Automata Theory. We also hope to enlist other developers to 
help expand the L-FLAT feature set. 

Future work will include adding support for w-automata (using the support 
for coinduction on recent Logtalk versions) and other language mechanisms (e.g. 
attribute grammars), adding conversion to and from the XML format used by 
JFLAP in order to share languages and mechanisms definitions, adding more 
conversion operations between mechanisms (e.g. between context-free grammars 
and pushdown automata), expanding the current set of examples, and exploring 
possible options for developing a graphical user interface (a task hindered by the 
lack of Prolog standards for interfacing with graphical user interface toolkits). 



We are also considering taking advantage of the support for tabling present 
on some Logtalk-compatible Prolog compilers. We are confident that we can use 
Logtalk support for conditional compilation in order to provide an implementa- 
tion fallback for Prolog compilers that do not support tabling or where tabling 
support is an optional feature that might not be present at runtime. 
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Fig. 1. Main L-FLAT entities and main predicates 



